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ABSTRACT 

In  support  of  a request  from  the  Air  Force  Avionics  Laboratory,  a 
model  of  the  F-16  Fire  Control  Computer  (FCC)  Operational  Flight  Program 
(OFF)  was  developed.  The  initial  specification  required  that  this  model 
allow  for  possible  changes  to  the  rate  of  accomplishment  of  various  OFP 
mode-dependent  tasks.  Tlie  reconfiguration  of  the  input  and  output  tasks 
and  the  processing  reserve  were  of  particular  interest. 

In  order  to  determine  the  most  useful  approach,  the  various  com- 
puter system  modeling  relationships  are  first  reviewed.  Based  on  the 
author's  background,  the  real  world  system  and  the  modeling  goals,  a 
discrete  event  queue  level  simulation  using  SIMSCRIPT  II. 5 is  selected 
as  the  desired  approach. 

The  basic  features  of  the  F-16  FCC  and  the  OFP  are  discussed  and 
a description  of  the  task  movement  in  the  system  is  provided.  This 
description  is  used  to  detail  the  various  rate  groups  and  their  member 
tasks.  The  model  is  verified  by  comparison  against  data  derived  from  an 
actual  system  run  and  a statistical  analysis  provided  by  the  OFP  manu- 
facturer . 

The  verification  process  showed  that  all  the  original  design 
objectives  were  met,  although  several  areas  of  possible  improvement  to 
the  model  are  indicated  and  discussed. 
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A DISCRETE-EVENT  DIGITAL  SIMULATION 
MODEL  OF  THE  F-16  FIRE  CONTROL 
COMPUTER  OPERATIONAL  FLIGHT 
PROGRAM  USING  SIMSCRIPT  II. 5 


I . INTRODUCTION 


The  science  of  "systems  analysis"  has  been  developed  to  aid  engineers 
and  managers  to  understand  and  evaluate  the  consequences  of  changes  to 
large,  complex  systems.  Many  efforts  exist  in  the  literature  where  tech- 
niques of  systems  analysis  have  been  applied  to  computer  systems.  These 
techniques  or  tools  are  applied  to  hardware,  software,  and  to  entire 
computer  systems.  These  efforts  compose  a significant  portion  of  what  is 
knoim  as  computer  performance  evaluation  (CPE) . This  paper  discusses  the 
technique  and  application  of  one  tool,  simulation,  to  investigate  the  task 
timing  relationships  in  the  F-16  fire  control  computer  (FCC)  operational 
flight  program  (OFP) . The  FCC  is  the  controlling  device  of  the  F-16  Fire 
Control  System  (FCS). 

Background 

The  Air  Force  Avionics  Laboratory  (AFAL)  has  been  directed  to  conduct 
an  independent  assessment  of  the  F-]6  fire  control  computer  OFP.  The 
testing  and  evaluation  of  the  OFP  requires  the  use  of  a software  test 
stand . 

The  test  stand  simulates  the  various  flight  conditions  of  the  F-16 
and  all  aircraft  subsystems,  except  the  FCS,  that  are  necessary  to  verify 
the  effectiveness  of  the  OFP.  An  actual  FCC  executing  the  OFP  is  attached 
to  the  aircraft  simulation  to  complete  the  software  test  stand  as  shown 
in  Figure  1.  A more  detailed  description  of  the  test  stand  is  given  in 
Chapter  IV. 


Figure  1.  AFAL  F-16  Software  Test  Stand  - Simplified 
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It  is  presently  envisioned  that  another  test  stand  will  be  built  at 
Hill  AFB,  Utah  to  support  Air  Force  Logistics  Command  (AFLC)  functions. 

During  the  early  evaluation  of  the  OFF,  AFAL  determined  that  certain 
system  and  flight  conditions  caused  the  OFF  to  enter  a system  failure 
state  called  a "timeout."  In  an  effort  to  anticipate  when  a timeout  twuld 
occur,  an  extensive  CPE  effort  is  underway  at  AFAL  and  at  General  Dynamics, 
the  OFF  manufacturer. 

Problem  Statement,  Approach,  and  Goals 

The  AFAL  Advanced  Systems  Group  (AFAL/AAF-3)  requested  that  a model 
of  the  test  stand  be  developed.  The  model  would  become  a tool  to  be  used 
by  CPE  personnel  to  study  possible  improvements  to  the  OFP  and  to  the  test 
stand  configuration.  The  processing  reserve  and  the  input/output  bus 
transfer  reserve  in  the  OFP  were  of  particular  interest. 

The  approach  to  solve  the  problem  was  to  accomplish  the  following 
steps  sequentially: 

1.  Define  the  goals  of  the  model. 

2.  Learn  a simulation  language. 

3.  Identify  the  task  parameters  of  the  OFP  and  of  the  test  stand 
devices . 

4.  Develop  the  model. 

5.  Obtain  the  data  to  verify  the  operation  of  the  model. 

6.  Operate  the  model  under  various  changes  in  parameters. 

The  following  goals  have  been  established  through  consultation  with 
AFAL/MF-3  to  define  the  model  characteristics  needed  to  study  the  OFP; 
it  must  allow  for  changes  in  the  OFP  task  scheduling  sequence;  it  must 
allow  for  program  execution  to  be  held  up  while  awaiting  termination  of 
an  executing  OFP  task  in  the  FCC  main  processor  and  the  FCC  bus  controller; 
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it  must  be  sufficiently  documented  for  ease  in  use  and  modification;  it 
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must  provide  sufficiently  accurate  statistics  to  form  a basis  for  making 
management  decisions;  it  must  reflect  FCC  mode  of  operation;  and  it  must 
allow  for  the  FCC  background  task  interrupt  and  task  restart  capability. 
AFAL/iVAF-3  was  also  interested  in  the  evaluation  of  different  Software 
Test  Stand  configurations.  This  was  not  feasible  with  the  model  level 
needed  to  achieve  the  goals  established  for  OFF  investigation.  The  devel- 
opment of  an  additional  model  was  not  possible  in  the  time  constraints 
of  this  work. 

Scope 

The  depth  of  the  investigation  was  determined  from  the  established 
goals  to  require  a queue  level  model  of  the  OFF.  A simulation  model  was 
chosen  to  implement  the  model  because  of  the  need  to  (1)  maintain  accurate 
operating  conditions,  (2)  explore  task  assignment  alternatives,  and  (3) 
control  the  passage  of  time.  All  data  input  to  the  simulation  model  was 
deterministic  data  for  simplification. 

This  report  discusses  a brief  summary  of  various  methods  in  model 
construction  (Chapter  II)  and  includes  summary  information  necessary  for 
a basic  understanding  of  SIMSCRIFT  II. 5 (Chapter  III).  A detailed  descrip- 
tion of  the  OFF  as  it  is  currently  documented  is  contained  in  Chapter  IV. 
The  actual  design  of  the  simulation  model  and  how  it  differs  from  the  OFF 
is  discussed  in  Chapter  V.  The  model  verification  results  and  conclusions 
of  this  work  and  suggested  improvements  are  contained  in  Chapter  VI.  A 
listing  of  the  simulator  model  is  found  in  Appendix  A and  OFF  Segment 
Definitions  are  found  in  Appendix  B.  A list  of  abbreviations  is  found  in 
Appendix  C. 
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II.  THE  ART  OF  NODELIN'G 


Computer  systems  have  been  studied  on  many  different  levels.  Each 
level  characterizes  the  system  by  particular  relationships,  parameters, 
and  events.  These  particular  characteristics  can  be,  and  generally  are, 
different  as  the  level  of  detail  is  changed.  Any  analysis  of  a complex 
system  attempts  to  study  tlie  effects  of  a modified,  "simple"  system  com- 
posed of  only  the  significant  variables  and  relationships.  Tliis  reduc- 
tion of  the  total  system  to  a limited  system  is  defined  here  to  be  the 
modeling  task.  Through  the  use  of  a model,  the  system  is  reduced  to  an 
entity  that  is  an  abstraction  and  yet  still  understandable.  Model  building 
constantly  poses  a problem  for  the  model  builder  of  balancing  the  need  for 
system  detail  with  the  need  to  make  the  model  that  will  provide  a solution 
to  the  problem.  Where  system  detail  is  excluded  from  the  model,  one  must 
"fill  in"  with  assumptions  about  tliat  detail.  Tliese  assumptions  must  be 
tested  against  the  actual  system  operation  whenever  possible. 

A model  is  intended  to  aid  system  analysis.  However,  there  are  some 
risks  involved  in  this  technique.  One  of  the  risks  is  that  the  investment 
of  time  and  effort  may  not  produce  a useful  benefit.  This  can  occur  when 
the  investigator  relies  too  much  on  the  modeling  method  and  fails  to  apply 
his  own  initiative  to  develop  the  model.  Model  building  must  be  regarded 
as  an  art  and  not  as  a science. 

Another  common  problem  would  develop  if  the  investigator  were  to 
attach  an  excessive  degree  of  significance  to  the  output  of  the  model. 

A model  can  never  predict  beyond  the  range  of  its  assumptions,  and  a model 
is  only  as  useful  as  the  image  it  presents  of  the  real  world  system. 
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Because  of  the  cost  and  talent  involved,  model  building  may  not  pro- 
duce a valid  image  of  the  real  world  system.  It  must  be  remembered  that 
the  model  produced  will  not  be  a unique  model  and  will  always  contain  a 
degree  of  imprecision. 

This  chapter  discusses  the  relationship  of  computer  simulation  models 
to  other  types  of  models.  Of  the  three  discrete  event  modeling  techniques, 
the  event  scheduling  approach  is  discussed  in  detail. 

Model  Classification 

Models  have  been  classified  by  several  schemes  (Ref  21:7,  23:29,  10:12). 
Of  interest  here  are  only  simulation  models.  Shannon  places  digital  com- 
puter simulation  models  next  to  mathematical  models  as  shown  in  Figure  2. 

It  should  be  noted  that  all  models  in  Figure  2 are  classes  of  simulation 
models  and  a computer  may  be  used  in  some  portion  of  any  of  these  models. 
Computer  system  simulation  is  a methodology  to  solve  <i  problem  using  a 
model  of  a real  world  computer  system.  This  is  not  to  be  confused  with 
computer  simulation  which  uses  models  which  are  not  necessarily  images  of 
real  world  computer  systems. 

The  type  of  simulation  model  tliat  is  developed  is  based  on  its  intended 
use,  the  goals  of  the  investigation,  the  level  of  detail,  and  the  real 
world  system.  Changes  in  the  system  state  will  usually  be  of  major  impor- 
tance when  studying  the  real  world  computer  systems.  These  state  changes 
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can  occur  continuously  or  at  discrete  moments  in  time  depending  on  the 
defined  state  parameters.  Thus,  the  model  of  the  computer  system  is  often 
built  in  the  time  domain.  This  allows  the  model  to  control  time  and, 
therefore,  provide  the  tools  of  time  expansion,  compression,  interruption, 
and  restart  capability.  Tlie  speed  of  the  simulating  computer  is  independ- 
ent of  the  model  for  all  practical  purposes. 

The  goals  of  this  investigation,  as  well  as  the  attributes  of  the 
system  being  modeled  allow  for  changes  in  system  state  to  occur  at  distinct 
moments  in  time.  Tliis  condition  is  best  described  in  a discrete  event 
model.  Here  an  event  denotes  a change  in  the  system  state.  A discrete 
event  model  requires  a clock  to  be  maintained  that  is  advanced  after  each 
change  of  the  system  state.  The  amount  of  advance  corresponds  to  the  real 
time  required  to  elapse  before  the  next  state  change. 

There  are  three  alternative  discrete  event  modeling  techniques  described 
by  Fishman  (Ref  10).  Tliese  techniques  are  related  to  various  simulation 
programming  languages.  SIMSCRIPT  and  GASP  are  related  to  the  event  sched- 
uling approach.  GPSS  and  SIMULA  are  related  to  the  process  interaction 
approach.  And  CSL  is  related  to  the  activity  scanning  approach.  Fishman 
defines  a process  as  "a  sequence  of  events  ordered  on  time,"  an  activity 
as  "a  collection  of  operations  that  transform  the  state  of  an  entity," 
and  an  event  as  "a  change  in  state  of  an  entity"  (Ref  10:24). 

A model  type  that  can  allow  for  variations  of  task  (job)  parameters 
as  well  as  Identify  the  system  state  (mode)  is  a "queuing"  model.  Jobs 
enter  the  system  and  compete  against  existing  jobs  for  system  resources. 

When  the  resources  are  not  available,  the  job  is  placed  in  a waiting  line 
or  a queue  until  the  resources  become  available.  Each  task  must  contain 
parameters  to  describe  the  time  and  resources  required  to  complete  the 
task.  Resource  management  policies  are  often  analyzed  using  a queuing 
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model  (Ref  23:34).  An  entire  system  can  be  modeled  as  a network  of  queues 
and  their  relationships. 
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Event  Scheduling  Approach 

Only  the  event  scheduling  approach  to  discrete  event  simulation  is 
included  here  because  this  approach  permits  the  determination  of  the  sys- 
tem state  at  the  OFP-event  level  in  the  most  straightforward  manner.  As 
will  be  seen  in  Chapter  IV,  the  OFP  is  composed  of  a series  of  task  lists 
which  are  easily  represented  as  a set  (queue)  of  jobs  to  be  completed. 

Tlie  reader  is  referred  to  Fishman  for  a discussion  of  the  other  approaches 
(Ref  10:38,  40).  The  use  of  SIMSCRIPT  II. 5 makes  use  of  the  event  sched- 
uling approach.  This  language  was  available  on  the  AFIT  computer  facility, 
and  GASP  was  not  available. 

A change  in  system  state  occurs  each  time  a task  enters  the  system 
and  each  time  a task  completes  execution  and  departs  the  system.  Associated 
changes  in  state  occur  when  the  resource  or  server  becomes  busy  or  is  idled. 

When  a task  enters  the  system,  it  identifies  its  server  requirements 
and  its  service  time.  The  server  is  checked  for  availability.  If  the 
server  should  be  idle  when  the  task  enters,  the  server  is  placed  In  a busy 
condition.  The  task  completion  time  is  Identified,  and  the  task  completion 
is  scheduled.  If  the  server  should  be  busy  when  the  task  enters,  the  task 
is  placed  in  a queue.  Tliis  arrival  event  is  shown  in  a flowchart  in 
Figure  3. 

When  a task  has  received  the  required  service,  it  departs  the  system. 

As  shown  in  Figure  4,  this  task  completion  frees  the  server,  which  is  now 
available  for  another  task.  Therefore,  the  queue  is  checked  to  determine 
if  a task  is  awaiting  service.  If  the  queue  is  empty,  the  server  is  placed 
in  an  idle  condition.  If  there  is  a waiting  task  in  the  queue,  the  server 
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starts  servicing  or  executing  the  new  task,  the  new  task  completion  time 
is  identified,  and  the  task  completion  is  scheduled. 

The  last  Instruction  in  the  arrival  event  and  the  departure  event  is 
"Select  the  Next  Event."  This  instruction  returns  control  to  the  simula- 
tion "dispatcher"  that  makes  the  discrete  event  simulation  work.  The 
dispatcher  is  an  executive  scheduler  and  is  often  called  a control  or 
timing  routine.  As  an  event  is  scheduled,  an  entry  is  made  in  a special 
list  to  identify  the  event  and  when  it  is  to  begin  execution.  The  dis- 
patcher searches  that  list  to  find  the  next  event  start  time,  the  simu- 
lated time  is  advanced  to  this  next  start  time  and  the  event  is  "started." 

A queue  usually  has  a rule  for  selecting  the  next  task  to  be  placed 
in  service.  Tills  rule  is  called  a queue  discipline.  The  discipline  can 
select  the  task  to  be  removed  from  the  queue  based  on  a task  parameter 
(such  as  service  time  or  priority)  or  on  an  order  of  task  arrival  (such 
as  first- in-first-out  or  last-in-f irst-out) . 

Several  procedural  features  can  be  added  to  the  arrival  and  ('eparture 
events.  An  event  may  need  to  schedule  itself.  This  would  allow  tie  model 
to  be  self-generating  and  thus  a simulation  could  continue  without  requir- 
ing external  data. 

It  is  often  possible  to  combine  the  arrival  and  the  departure  events. 

This  occurs  if  the  queue  is  never  in  an  empty  condition,  i.e.,  there  is 
no  possibility  that  the  server  will  become  idle.  This  condition  would 
result  when  several  queues  feed  a single  server  and  all  are  not  empty  at 
once.  The  addition  of  a large  repeated  background  task  would  also  provide 
this  option.  This  feature  is  used  in  the  model  and  is  discussed  in  Chapter  V. 

To  aid  in  efficient  use  of  computer  memory,  records  of  completed  tasks 
are  often  discarded  (destroyed).  This  feature  may  not  be  desirable,  how- 
ever, due  to  some  purpose  of  the  model. 
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III.  ESSENTIALS  OF  SIMSCRIPT  I I. 5 


This  chapter  provides  a brief  review  of  the  SIMSCRIPT  II. 5 language 
characteristics.  It  is  intended  only  as  a general  review  and  the  reader 
is  referred  to  the  literature  (Ref  22)  for  the  language  details. 

A simulation  language  provides  the  basic  mechanism  for  creating  a dis- 
crete event  simulator.  Functional  flow  charts  are  first  used  to  define 
a model  of  a real  world  system.  The  pictorial  model  is  then  coded  by 
means  of  a simulation  language  to  form  the  simulator.  Simulation  lan- 
guages such  as  GASP,  GPSS,  and  SIMSCRIPT  have  special  built-in  character- 
istics for  dealing  with  discrete  events  and  for  gathering  certain  statistics. 

SIMSCRIPT  is  a general  purpose  programming  language,  which  is  com- 
piled directly  into  an  assemble- language  code  by  its  compiler.  It 
provides  flexibility  for  statistical  outputs,  mathematical  manipulations, 
and  programmer  expression  in  simulator  design.  The  simulated  system  is 
composed  of  "entities,"  "attributes,"  and  "sets."  An  entity  denotes  an 
object  of  the  system  such  as  a task,  a variable,  a channel,  a memory  block, 
a server,  etc.  An  entity  is  described  by  its  attributes.  The  status  of 
the  system  is  determined  by  the  current  values  of  these  attributes. 

Entities  can  be  grouped  into  sets.  A set  can  arrange  the  entities  on  an 
order  basis  of  first- in-flrst-out  (FIFO),  last-in-first-out  (LIFO),  or 
ranked  on  the  value  of  some  attribute.  Sets  are  used  as  queues,  etc. 

Entities  interact  with  specific  conditional  activities  called  "events." 
An  event  is  like  a subroutine,  and  is  composed  of  SIMSCRIPT  statements. 

An  event  always  occurs  at  a specific  time  and  changes  the  state  of  the 
system  by  changing  the  attribute  values  of  the  interacting  entities.  A 
process  which  has  a finite  duration  must  usually  be  modeled  and  programmed 
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as  at  least  two  events;  one  which  initiates  the  process  and  one  that  ter- 
minates the  process.  Typical  events  would  be  job  arrival,  job  schedule, 
request  memory,  request  processor,  end  computation,  begin  input,  begin 
output,  end  input,  end  output,  release  memory,  etc. 

The  SIMSCRIPT  compiler  automatically  creates  an  executive  scheduler, 
a simulation  control  or  timing  routine,  that  advances  the  simulated  time 
to  the  time  of  the  next  scheduled  event  and  calls  the  events  in  proper 
sequence.  The  SCHEDULE  statement  allows  the  modeler  to  define  when  an 
event  is  to  occur  in  the  future.  An  event  can  schedule  itself  or  another 
event . 

The  input  to  the  simulator  is  a description  of  the  real  world  hard- 
ware and  software  configuration,  and  a description  of  the  workload.  The 
workload  is  represented  by  jobs  or  tasks  that  enter  the  simulator  and  place 
demands  for  system  resources  or  services.  All  Initializations  must  be 
stated  in  program  statements  in  SIMSCRIPT  II. 5. 

The  output  of  the  simulator  can  be  a snapshot  of  the  system  status 
at  some  point  in  the  simulation  run.  The  programmer  has  the  capability 
to  measure  various  activities  and  output  a basic  statistical  summary  of 
what  occurred.  The  attribute  values  are  monitored  and  summary  variables 
are  updated  to  provide  a simple  means  to  produce  the  statistics. 

Some  activities  are  stochastic  and  the  language  Includes  facilities 
which  ease  the  burden  in  the  generation  of  random  variates  that  fill  a 
desired  probability  distribution.  There  are  ten  random  number  generators 
and  eight  distributions  available. 

SIMSCRIPT  II. 5 contains  a program  section  called  the  PREAMBLE.  Pro- 
gram statements  in  the  PREAMBLE  are  nonexecutable  and  provide  the  compiler 
with  model  definitions  and  relationships.  The  ownership/membership  or 


12 


structure  of  entities,  attributes,  and  sets  are  defined.  The  existence 
of  events,  routines,  variables  (name,  type,  and  dimension),  and  arrays 
are  stated.  The  summary  variables,  attributes,  and  types  of  statistics 
desired  are  described.  The  PREAMBLE  can  be  omitted,  in  which  case  certain 
default  conditions  are  used. 

Another  program  block  is  the  MAIN  section.  This  is  the  main  routine 
of  the  simulator.  It  is  in  MAIN  (for  the  model  developed  in  this  work) 
where  the  system  Initialization  occurs.  Variables  are  set  to  their  start- 
ing values.  Sets  are  built.  Entities  are  either  CREATEd  or  READ  in  from 
data  cards.  Entities  are  FILEd  in  sets.  Space  for  dimensioned  or  sub- 
scripted variables  is  RESERVEd.  Events  are  SCHEDULEd.  The  simulation  is 
started  with  a START  SIMULATION  statement. 

The  simulation  will  stop  when  a variable  reaches  a stated  value  or 
there  are  no  more  scheduled  events.  Usually  the  simulation  is  stopped 
after  a certain  period  of  simulated  time  has  elapsed,  i.e.,  TIME.V  equals 
some  value,  or  when  a queue  overflows,  i.e.,  N.set  exceeds  some  value, 
or  when  a certain  statistic  is  achieved,  i.e.,  a summary  variable  equals 
some  value. 

The  language  is  very  efficient  but  does  require  some  programming  skill. 
It  can  be  used  to  simulate  a complex  system  or  to  do  general  prograiuning . 

Its  special  features  make  it  a significant  time-saver  when  compared  to  the 
nonsimulation  higher  order  languages.  For  example,  one  SIMSCRIPT  statement 
often  replaces  an  entire  FORTRiXN  subroutine.  A drawback  may  be  the  require- 
ment for  the  programmer  to  learn  how  to  express  algorithms  by  the  language 
statements.  It  is  often  difficult  to  debug  a large  simulator  due  to  the 
automatic  generation  of  data  structures  and  set  relationships.  The  author 
chose  to  use  SIMSCRIPT  11.5  for  the  simulator  in  this  study  due  to  his 
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limited  background  in  other  simulation  languages  and  due  to  the  availabil- 
ity of  SIMSCRIPT  II. 5 on  the  AFIT  computer  system. 


IV.  F-16  FIRE  CONTROL  COMPUTER 
OPERATIONAL  FLIGHT  PROGR.\M 


This  chapter  develops  the  concept  of  avionic  software.  It  discusses 
an  evaluation  tool,  the  software  test  stand.  A description  of  the  Fire 
Control  System  is  included  that  describes  the  system  requirements  or  func- 
tions, system  mode  operations,  and  OFP  design  construction.  Emphasis  is 
made  to  the  movement  of  data  in  the  FCS.  Tlie  reader  is  encouraged  to  pay 
particular  attention  to  the  description  of  the  OFP  modes  of  operation  and 
the  OFP  segment  discussion  as  the  model  simulates  all  OFP  modes  at  the 
segment  level. 


Associated  Terminology 

"Avionic  Software"  is  a term  that  is  frequently  used  to  identify 

1 

vastly  different  concepts.  To  understand  the  relationship  of  an  operational  ! 

flight  program  (OFP)  to  the  term  of  avionic  software,  the  following  definl-  t 

tions  are  suggested  by  Trainor  (Ref  25:998):  j 

1.  Avionic  Mission  Software  (ILS)  : Software  which  executes  in 
the  flight  computer  and  performs  direct  mission  related 
functions.  An  analogous  term  is  "embedded"  software. 

2.  Avionic  Support  Software  (SS) : Software  which  is  required 
to  aid  in  the  design  and  production  of  avionic  systems 
(both  hardware  and  mission  software). 

3.  Operational  Flight  Program  (OFP):  The  OFP  contains  those 
functions  which  execute  in  the  flight  computer  in  (or  near) 
real-time  and  perform  the  primary  aircraft  mission  func- 
tions. (Examples  for  the  F-16  are  the  following  functions: 

Executive  control,  navigation,  guidance,  stores  management, 
fixtaking,  in-flight  system  test,  bus  control,  fuel  manage- 
ment, combat  energy  management,  data  management,  and  | 

targeting.)  , 

A.  Operational  Test  Program  (OTP):  A comprehensive  program  for 
flight-line  diagnosis  and  maintenance.  It  usually  is  in  the 
form  of  aQlght-line  loadable  software  package  that  executes 
in  the  actual  flight  computers  while  these  computers  are  still 
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Figure  5.  Avionic  Software  Terminology 


resident  in  the  aircraft.  The  program  will  identify  system 
faults  and  will,  therefore,  certify  the  computer  air  worthi- 
ness. (Examples  of  F-16  functions  include:  computer  health 
tests,  input/output  hardware  tests,  sensor  operation  tests, 
and  fault/unit  isolation/identification.) 

The  relevant  terminology  is  depicted  in  Figure  5 and  .shows  the  relation- 
ships between  terms. 


Characteristic  Differences  of  Avionic  Mission  Software 

Avionic  mission  software  differs  from  the  usual  Automatic  Data  Process- 
ing (.VDP)  software  in  several  respects.  Avionic  mission  software  is  used 
to  close  several  multiple  frequency  control  loops.  Ttie  problems  to  be 
solved  are  represented  in  terms  of  radar,  navigation,  and  weapon  delivery 
functions,  i.e.,  algorithms  (equations  and  logic.)  with  timing,  and  through- 
put constraints.  Tliis  could  be  compared  with  an  on-line  realtime  control 
of  some  manufacturing  process.  In  addition,  the  software  must  present  all 
pertinent  information  to  the  aircrew  displays  and  react  in  realtime  to 
Insure  aircrew  safety.  Further,  tlie  total  software  package  must  provide 
absolute  control  over  weapon  release  so  that  nuclear  weapons  might  bo 
placed  under  its  control. 
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The  greatest  number  of  inputs  to  the  avionic  computer  come  via  analog- 


to-digital  converters,  from  sensors,  and  from  aircrew/aircraft  control 
actions.  Tliese  inputs  are  taken  without  regard  to  the  status  of  the  device 
that  caused  the  input.  Hardware  failures  must  be  detected  by  the  software 
in  order  to  provide  a continuous,  reliable  operation.  Tlie  computer  is 
absolutely  in-line  and  its  functions  cannot  be  bypassed,  postponed,  nor 
replaced . 

An  EXECUTIVE  is  a major  segment  of  an  OFF.  It  must  be  written  such 
that  as  it  interacts  with  other  functional  modules,  it  satisfies  the 
critical  areas  of  timing  and  control.  The  software  is  developed  as  a 
permanent  configuration  and  is  changed,  normally,  only  as  a result  of 
system  modification. 

The  necessity  for  correctness  in  the  OFF  logic  has  led  to  the  use 
of  a "software  test  stand"  to  perform  verification  and  validation  of  the 
critical  relationships. 

. 

.\FAL  Software  Test  Stand 

This  facility  provides  the  CFE  personnel  of  AFAL  with  the  real-time 
tool  needed  to  evaluate  the  OFF.  Figure  6 sliows  the  tost  stand  configura- 
tion (Ref  26).  It  contains  a DEC-10  host  computer,  a fire  control  computer 
which  has  been  instrumented  with  two  hardware  interfaces  (SCADU,  LIRT) , the 
analog-to-digital  interfaces  required  for  the  cockpit  controls  (stick,  rud- 
der, throttle),  a Fire  Control/Navigation  Fanel  (FCNF) , a bus  monitor  unit 
(BMU) , an  operator  keyboard,  and  the  display  devices.  Tlie  avionic  support 
software  is  executed  in  real-time  on  the  host  computer  and  the  mini-computers 
(i’DF-ll's).  The  mini-computers  control  the  displays  and  the  interfaces. 

Tlie  support  software  contains  avionic  subsystem  simulation  models,  data 
analysis  routines,  and  test  operator  control  capabilities  in  modular 
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segments.  Additionally,  external  environment  modules  provide  a parametric 
description  of  the  terrain,  weather,  targets,  atmosphere,  and  the  earth 
gravitational  effects  for  use  in  generating  test  scenarios. 

The  Discrete  Panel  represents  all  the  required  cockpit  switches  and 
additional  switches  that  allow  the  operator  to  select  the  simulation  mode 
of  operation.  The  cockpit  controls  allow  the  operator  to  "fly"  the  simu- 
lated aircraft.  The  BMU  provides  a means  for  a processor  to  monitor  and 
record  bus  messages,  identification  tags,  and  related  timing  information. 
The  Universal  Remote  Terminal  (URT)  simulates  the  operation  of  from  one 
to  32  remote  terminals  with  full  subsystem  avionic  communication  capa- 
bilities. The  aircraft  subsystems  are  simulated  on  the  DEC-10.  The  Heads 
Up  Display  (HUD)  gives  a simulated  "out-the-wlndow"  display  of  flight 
conditions.  Tlic  FCNP  provides  pilot  inputs/outputs  to  the  total  system. 
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The  SCADU  provides  access  to  the  FCC  internal  bus.  The  DMA- 10  is  a direct 
memory  access  unit  to  the  DEC- 10.  The  LSI  16  is  an  interfacing  computer 
hardware  unit.  The  Keyboard  allows  the  operator  to  communicate  with  the 
DEC-10,  the  PDP-ll's,  and  the  FCC.  The  FCC  is  an  actual  Magic  362F  avionic 
computer  manufactured  by  DELCO  Electronics. 

The  AFAL  Software  Test  Stand  is  used  to  verify  that  the  OFP  actually 
satisfies  its  design  functions.  Program  conflicts  are  identified  through 
the  testing  of  the  OFP  in  a simulated  operational  environment. 


Fire  Control  Computer  OFP  Function  Descriptions 

The  following  OFP  functions  are  described  in  the  "Computer  Program 
Development  Specification  for  the  Fire  Control  Computer  Operational  Flight 
Program"  (Ref  11) : 

The  navigation  functions  of  the  OFP  are  steering  and  cruise 
energy  management.  The  steering  computations  are  performed  in 
another  aircraft  subsystem,  the  Inertial  Navigation  Unit  (INU) . 

The  OFP  interfaces  the  INU  steering  problem  solution  to  the 
steering  display  devices.  The  cruise  energy  management  tasks 
present  to  the  pilot  the  flight  path  guidance  needed  to  maxi- 
mize the  aircraft  range,  endurance,  or  the  fuel  remaining  at 
the  destination. 

The  fixtaking  functions  provide  the  capability  to  update  the 
estimate  of  the  aircraft  present  position,  to  store  the 
coordinates  of  thirteen  mission  planning  positions  for  in- 
flight reference,  and  to  update  the  estimate  of  the  aircraft 
true  altitude.  Fixtaking  tasks  are  not  confined  to  the  FI.X 
mode  of  the  OFP. 

Tlie  air-to-air  combat  functions  Include  the  displays  and  con- 
trols required  to  fire  the  M61  gun  and  to  deliver  Sidewinder 
missiles.  Combat  energy  management  tasks  provide  the  pilot 
with  cues  to  devt  ’op  and  execute  effective  and  efficient 
aircraft  maneuvers  during  most  air-to-air  modes. 

The  air-to-ground  attack  functions  Include  the  capability  to 
attack  either  preplanned  or  in-f light-designated  surface  tar- 
gets. The  capability  includes  computation  for  automatic  and 
manual  ballistics,  course-to-release  point,  time-to-go,  auto- 
matic weapon  release,  rlpple-homblng,  laser  target  identifica- 
tion, visual  and  blind  deliveries,  and  radar  freeze. 


The  malfunction  analysis  functions  require  the  ability  to 
collect  and  store  FCS  faults,  to  initiate  subsystem  operational 
self-tests,  and  to  display  the  results  of  the  subsystem  self- 
tests. The  initialization,  hardware  error,  addressing  error 
and  power  down  requirements  are  satisfied. 

The  stores  data  function  is  to  Interface  the  stores  manage- 
ment subsystem.  Weapon  parameters  must  be  available  to  insure 
accurate  air-to-air  combat,  air-to-ground  attack,  and  energ>' 
management . 

The  heads  up  display  (HUD)  functions  provide  large  amounts  of 
data  to  the  pilot  in  the  form  of  symbols,  scales,  and  windows. 
This  allows  the  pilot  to  see  certain  critical  information  while 
he  is  looking  out  the  aircraft  windscreen. 

Data  entry/display  functions  include  processing  logic  to  control 
the  FCNP,  to  input  data  into  the  FCC  memory,  to  display  the 
data  associated  with  the  FCC  mode  and  options,  and  to  determine 
a steering  point. 

Mission  planning  functions  Include  the  ability  to  store  and 
access  destination  coordinate  data,  mark  point  coordinate 
data,  and  offset  airapoint  data.  This  assists  the  pilot  to 
increase  weapon  delivery  effectiveness. 

Tlie  support  utility  functions  are  the  common  utility  routines 
shared  by  various  segments  of  the  OFF.  There  are  11  mathemat- 
ical functions  required  by  the  OFF.  The  ability  to  mask  and 
unmask  bus  interrupts  and  to  provide  common  exit  procedures 
from  OFF  segments  are  also  required  by  the  OFF. 

Bus  control  functions  include  control  of  tlie  serial  data 
transmission  over  the  multiplex  (MUX)  buses  between  aircraft 
subsystems,  control  of  the  analog-to-digital  converters  (ADC), 
reading  the  "sample  and  hold"  hardware  for  discrete  input 
from  seven  points  (such  as  the  throttle  power  setting  and  the 
landing  gear) , detection  of  the  operational  reliability  of  the 
hardware  involved  in  the  above  activities,  and  formating  data 
for/after  transmission  on  the  MUX  buses. 


Fire  Control  Computer  OFF  Mode  Descriptions 

The  OFF  operates  in  one  of  fifteen  mutually  exclusive  modes.  A 
description  of  these  modes  is  provided  in  the  following  paragraphs: 
1.  "Air-to-Alr"  Modes 

a.  Dogfight  (1) 

b.  A/A  Missiles  (2) 

c.  Snapshoot  (3) 

d.  LCDS  (4) 
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2.  "FCC  Air- to-Ground"  Modes 

a.  CCIP  (5) 

b.  Dive  Toss  (6) 

c.  Beacon  (7) 

d.  CCRP  (8) 

e.  Strafe  (9) 

f.  LADD  (10) 

3.  "Air- to-Ground"  Modes 

a.  CCIP  (5) 

b.  Dive  Toss  (6) 

c.  Beacon  (7) 

d.  CCRP  (8) 

e.  Strafe  (9) 

f.  L.U)D  (10) 

g.  EO  Weapons  (11) 

4.  Non-Weapon  Delivery  Modes 

a.  ALT  CAT  (12) 

b.  FIX  (13) 

c.  TEST  (14) 

d.  Baseline  (15) 

The  numbers  in  parentheses  are  used  in  the  model  to  define  the  current  OFP 
mode  of  operation. 

The  Dogfight  mode  computes  and  displays  snapshoot  gunnery  and  dynamic 
missile  launch  zone  solutions.  Combat  energy  management  is  not  provided 
in  this  air-to-air  mode. 

The  A/A  Missiles  mode  computs  the  dynamic  launch  zone  information 
(maximum  and  minimum  missile  launch  ranges,  aiming  and  aircraft  lead  pur- 
suit steering  commands)  necessary  for  the  use  of  the  Sidewinder  missiles 
against  maneuvering  and  non-maneuvering  targets.  Target  dynamics  and 
missile  performance  determine  the  solution.  An  override  feature  provides 
automatic  target  acquisition.  Dynamic  wing  twist  is  also  calculated  to 
provide  corrections  required  to  accurately  point  the  missile  seeker. 

The  Snapshoot  mode  displays  a simulated  bullet  stream  impact  point. 

It  provides  the  pilot  with  optimal  transient  firing  opportunities. 
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The  LCDS  mode  provides  the  gunnery  solution  to  the  Lead-Computing 
Optical  Sighting  (LCOS)  problem.  This  is  based  on  data  from  aircraft 
sensors  (primarily  the  angular  body  rates  of  the  F-16) , target  range 
rate  and  range,  and  the  aiming  reticle  on  the  heads-up-display  (HUD) . 
n,e  pilot  must  smoothly  maneuver  his  aircraft  to  place  the  target  within 
the  aiming  reticle.  Tlie  OFF  positions  the  aiming  reticle  on  the  HUD  to 
indicate  projectile  firing  path. 

The  CCIP  mode  is  used  to  deliver  air-to-ground  weapons  under  visual 
conditions  in  either  level  or  dive  deliveries.  The  OFF  displays  on  the 
HUD  the  Continuously  Computed  Impact  Point  (CCIP) . 

The  Dive  Toss  mode  is  used  to  visually  designate  targets,  to  provide 
steering  to  the  weapon  release  point,  to  generate  automatic  release  of  the 
weapon,  and  to  compute  the  pull-up  flight  path  cues  on  the  HUD. 

The  Beacon  mode  is  used  to  attack  targets  that  are  located  by  their 
relative  position  in  reference  to  a ground-based  radar  beacon.  Tlie  pilot 
proceeds  as  if  in  CCRP  mode  after  the  target  is  identified. 

I The  Continuously  Computed  Release  Point  (CCRP)  mode  utilizes  a basic 

j coordinate  bombing  mechanization  and  the  radar  ground  map  features  to 

t 

j provide  an  adverse  weather,  blind-attack  delivery. 

[ The  strafe  mode  is  employed  to  attack  ground  targets  with  the  M61  gun. 

j Weapon  impact  point  is  displayed  to  the  pilot. 

' I 

The  Low  Altitude  Drogue  Delivery  (LADD)  mode  is  provided  for  blind  ‘ 

i 

I delivery  of  nuclear  weapons.  Except  for  the  pull-up  and  the  vertical 

steering  information,  this  mode  is  the  same  as  the  CCRP  mode. 

’ 

The  electro-optical  (EO)  weapon  mode  is  employed  to  deliver  tele- 
vision guided  weapons  on  ground  targets  in  either  level  or  dive  release 
conditions.  This  mode  requires  no  processing  in  the  implementing  OFF 
component.  EO  symbology  is  displayed  on  the  HUD. 
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The  ALT  CAL  mode  uses  fire  control  radar  (FCR)  data,  a computed  D- 


value,  and  terrain  elevation  to  update  the  estimate  of  the  airplane 
altitude.  The  D-value  is  a measure  of  the  difference  between  the  sensed 
air  density  and  the  "standard  day"  density  altitude.  The  accuracy  of 
fixtaking  and  weapon  delivery  functions  depend  on  the  accuracy  of  the 
aircraft  altitude  estimate. 

The  FIX  mode  permits  the  execution  of  the  cruise  energy  management 
tasks  and  associated  tasks  to  update  the  aircraft  position  estimate. 
Critical  fixtaking  tasks  are  executed  in  the  appropriate  weapon  delivery 
modes . 

The  Test  mode  is  used  to  retrieve  a maintenance  fault  table  which 
consists  of  all  faults  reported  during  the  FCC  self-test.  It  is  also  used 
to  initiate  subsystem  built- in- tests  that  interrupt  the  normal  operation 
of  the  subsystem. 

The  Baseline  mode  has  the  lowest  mission  priority.  It  could  be  con- 
sidered a "standby"  mode  of  operation.  In  this  mode  the  OFF  only  does 
the  self-test  tasks  and  essential  navigation  and  control  functions. 

The  OFF  Structure 

The  construction  of  the  OFF  was  implemented  through  a top  doxcn  design. 
The  highest  level  contains  computer  program  components  (CFC)  which  repre- 
sent the  building  blocks  used  to  implment  the  OFF  functional  requirements 
described  on  page  19.  Fifteen  components  have  been  identified  and  are 
listed  in  Table  I (Ref  11) . Component  interfacing  is  accomplished  by  the 
executive  component  and  the  sharing  of  data  items.  CPCs  are  partitioned 
to  form  the  next  design  level. 

Tlie  OFF  is  controlled  by  the  initialization  and  error  handling  com- 
ponent, the  system  control  component,  the  executive  component,  and  the  bus 
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Table  I. 


OFF  Computer  Program  Component  Description 


Component 

Number 

Name 

l.X 

Executive 

EX 

4 

2.x 

System  Control 

SC 

10 

3.x 

Bus  Control 

BC 

18 

4.x 

Initialization  & Error 
Handling 

IE 

5 

5.x 

Navigation  Support 

NS 

5 

6.x 

Fixtaking 

FX 

17 

7.x 

Cruise  Energy  Management 

CR 

4 

8.x 

Combat  Energy  Management 

CO 

4 

9.x 

Air-to-Air  Gunnery 

GN 

2 

1 10. X 

Air-to-Alr  Missiles 

AM 

4 

11. X 

Air-to-Ground  Attack 

AG 

13 

12.x 

Stores  Data  Select 

SS 

2 

13.x 

Data  Entry/Display 

DE 

1 

14.x 

Self- test 

ST 

1 

15.x 

Support  Utility 

su 

14 

where  X is  reserved  for  the  segment  number 
*Segment  Definitions  are  found  in  Appendix  B. 


control  component.  The  initialization  and  error  handling  component  assumes 
program  control  on  power  up  and  following  the  detection  of  certain  hard- 
ware and  software  errors.  The  system  control  component  controls  the  mode 
dependent  task  execution.  The  executive  provides  primary  interface  between 
components.  It  schedules  the  execution  of  time  dependent  tasks  and  ser- 
vices interrupts.  It  interleaves  lengthy,  mission-directed  tasks  with 
short,  periodic  service  tasks.  The  bus  control  component  controls  the 
MLIX  buses  and  the  input/output  data  flow. 

The  navigation  support  component,  cruise  energy  management  component, 
combat  energy  management  component,  and  the  air-to-ground  attack  component 
implement  the  associated  FCC  functions  and  provide  data  for  the  HUD.  The 
stores  data  select  component,  self-test  component,  and  the  support  utility 
component  implement  the  respective  OFF  functions.  The  fixtaking  component 
Implements  the  fixtaking  functions  and  provides  the  mission  planning  func- 
tion of  range  and  course  identification.  The  air-to-air  gunnery  component 
provides  the  implementation  of  the  air-to-air  combat  functions  as  they 
relate  to  the  solution  of  the  lead-computing  optical  sight  algorithms. 

The  air-to-air  combat  functions  that  involve  the  computation  of  the  dynamic 
launch  zone  for  effective  air-to-air  missile  launch  is  Implemented  in  the 
air-to-air  missiles  component.  The  data  entry/display  component  satisfies 
the  data  entry/display  functions,  the  mission  planning  functions  related 
to  data  storage  and  data  search,  and  the  self-test  function  of  test  result 
display . 

The  second  design  level  is  called  the  segment  level.  Segments  repre- 
sent the  executable  portion  of  the  OFF.  A segment  is  the  smallest  parti- 
tion of  code  that  can  be  scheduled  or  entered  through  an  interrupt.  Func- 
tionally related  segments  are  divisions  within  a component.  Segments  of 
the  same  component  are  scheduled  within  the  OFF  at  a frequency  that  will 
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insure  complete  OFF  mission  effectiveness.  A segment  is,  therefore,  an 
OFF  "task"  or  "Job." 

There  are  three  general  classes  of  interrupts:  periodic,  external, 
and  error  interrupts.  In  normal  operation,  error  interrupts  never  occur. 

-A  20  millisecond  timer  provides  the  periodic  interrupts.  FCC  task  sched- 
uling is  based  on  this  interrupt.  Each  20  millisecond  period  is  called 
a minor  frame.  A data  bus  interrupt  occurs  after  each  data  transfer 
period.  A software  interrupt  is  signaled  to  the  e.xecutiv'e  dispatcher  after 
each  executive  controlled  task  is  completed.  External  interrupts  occur 
after  an  infrequent  data  transfer  fault  and  at  the  completion  of  an  analog- 
to-digital  data  conversion.  A bus  data  transfer  fault  is  serviced  by  the 
bus  controller. 

The  OFF  logic  relies  on  the  mode  dependent  scheduling  of  tasks  and 
on  the  structural  design  of  the  OFF.  The  structural  design  consists  of 
periodic  "time  slice"  tasks  followed  by  "main  loop"  tasks.  Main  loop 
tasks  can  be  considered  to  be  "background"  tasks.  Time  slice  tasks  are 
executed  immediately  following  the  timer  or  clock  interrupt.  This  time- 
dependent  scheduling  is  accomplished  by  the  executive  componen*. . 

The  time  slice  tasks  are  divided  in  "rate  groups."  A rate  group  is 
a list  of  tasks  which  are  grouped  by  frequency  of  execution.  Tlie  rate 
groups  .are  named  by  their  frequency  of  execution,  i.e.,  50  Hz,  25  Hz,  12.5 
Hz,  6.25  Hz,  3.125  Hz,  1.5625  Hz,  and  the  1.5625  Hz  offset  rate  groups. 
Short,  periodic  service  tasks  are  scheduled  in  the  rate  groups  by  a sys- 
tem control  segment  at  a rate  to  satisfy  the  subsystem  refreshment  require- 
mt*nts.  In  the  model  "TS"  is  used  to  indicate  50  Hz  tasks,  "RG"  is  used  to 
identify  the  other  rate  group  tasks,  and  "ML"  is  used  to  refer  to  main 
loop  tasks. 
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Each  time  slice  interval  contains  time  for  the  execution  of  two  rate 


groups.  This  permits  a balanced  computational  load  as  shown  in  Figure  7. 
Each  "X"  in  Figure  7 represents  the  list  of  tasks  that  are  all  executed 
each  time  that  rate  group  is  scheduled.  The  Interval  shown  in  Figure  7 
repeats  itself  every  .64  seconds  and  is  called  a major  frame.  A major 
frame  is  thus  divided  into  32  minor  frames.  Note  that  there  are  two 
1.5625  Hz  rate  groups,  each  of  which  executes  once  in  a major  frame. 

Three  basic  main  loop  conf igurations  implement  the  OFF  weapon  delivery 
functions:  air-to-air  missiles  and  gunnery,  and  air-to-ground  attack. 

Tliese  tasks  require  lengthy  computations.  Cruise  energy  management  does 
not  require  a fast  execution  rate  and  is  assigned  to  a main  loop  task  list. 
The  main  loop  tasks  are  divided  into  two  repeating  lists  of  tasks  which 
are  called  "tracks."  Each  track  alternates  execution  for  a specific  mode- 
dependent  time  allotment.  The  executive  component  suras  the  execution  time 
spent  executing  each  track  and  schedules  the  required  track  to  be  executed 
next . 

Data  Movement  and  Bus  Control 

Data  transmissions  are  grouped  into  blocks  of  data.  A block  contains 
all  the  data  that  is  transmitted  between  two  particular  subsystems  during 
a specific  rate  group.  All  the  blocks  of  a rate  group  are  divided  into 
input  groups  and  output  groups.  Each  group  is  assigned  to  its  specific 
rage  group  as  a rate  group  task.  Since  it  is  desired  that  all  computations 
be  made  with  the  most  current  data  available  and  that  the  computation 
results  be  sent  to  the  subsystems  as  soon  as  possible,  tlie  input  task  is 
scheduled  as  the  first  task  in  each  rate  group  and  tlie  output  task  is 
scheduled  as  the  last  task  in  each  rate  group.  If  input  data  must  be 
formated,  a task  to  accomplish  the  formating  is  scheduled  immediately  after 
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Figure  8.  I/O  and  Computation  Sequence 


the  input  task.  Output  formating,  if  required,  occurs  immediately  before 
the  output  task.  Tlius  the  sequence  of  operations  within  each  minor  frame 
is  as  shown  in  Figure  8. 

A hardware  bus  controller  is  provided  to  Increase  central  processor 
unit  (CPU)  utilization.  The  OFP  bus  component  starts  the  bus  controller 
at  the  required  time  and  the  bus  controller  directs  the  proper  data  move- 
ment. The  CPU  then  begins  executing  main  loop  tasks.  When  the  data  trans- 
mission is  complete,  the  bus  controller  interrupts  the  CPU  and  the  rate 
group  tasks  are  executed.  Only  during  actual  1/0  data  transmission  does 
the  hardware  bus  controller  operate  independently  from  the  CPU. 

Should  the  bus  controller  detect  a transmission  fault  on  one  of  the 
MUX  buses,  the  other  bus  is  used  by  the  bus  controller  to  retransmit  the 
last  data  block.  If  a second  fault  is  detected,  the  defective  data  block 
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is  discarded  and  the  data  from  the  last  good  transmission  of  that  data 
block  is  used  as  the  input  to  the  current  frame  time  dependent  computa- 
tions. All  data  received  by  the  FCC  is  double  buffered  in  order  to  permit 
this  capability. 

There  are  three  types  of  transmission  on  the  MU.K  buses.  Tlie  first 
type  includes  data  blocks  that  are  moved  between  the  FCC  and  an  aircraft 
or  a FCS  subsystem  component.  It  also  includes  data  blocks  that  are  moved 
between  subsystem  components.  The  second  type  of  data  transmission 
appears  after  each  subsystem-to-subsystem  block  transmission  and  is  iden- 
tified by  the  suffix  Si\FE.  For  example,  "C02  S.iFE"  follows  transmission 
of  the  data  block  named  "C02."  SAFE  transmissions  signal  the  receiving 
subsystem  that  it  has  received  its  last  data  word.  It  is  a single  data 
word  called  a command  word.  SAFE  transmissions  are  detailed  in  Table  II. 

Hie  third  type  of  data  transmission  appears  in  the  1.5625  Hz  offset  rate 
group.  Hiese  transmissions  are  used  to  test  the  integrity  of  the  MUX 
buses  and  the  hardware  bus  controller.  The  communication  formats  required 
for  different  data  transmissions  are  shown  in  Figure  9.  A data  word  is 
.sent  every  20  microseconds.  The  control  and  status  data  words  are  required, 
as  indicated,  to  insure  that  the  proper  devices  have  control  of  the  MUX 
bus.  The  gap  time  duration  for  subsystem  to  (or  from)  FCC  communications 
is  between  2 and  5 microseconds.  Tlie  gap  time  duration  for  subsystem  to 
subsystem  communications  is  between  4 and  10  microseconds.  There  is  a gap 
time  that  is  hidden  in  Figure  9 that  exists  betwi-en  the  data  block  trans- 
missions. 'fills  gap  time  varies  between  17  and  37  microseconds  in  duration. 
Tlie  average  for  this  last  gap  time,  however,  is  approximately  20  microsecond 

The  data  block  descriptions  are  contained  in  Table  III.  Each  data  block 
is  identified  by  name,  word  size,  transmitter,  receiver,  transmission 
duration,  and  rate  group  task  to  which  the  block  Is  assigned.  Tliese  descrip 
tions  arc  used  in  Chapter  V to  develop  the  I/O  tasks. 


Table  II.  SAFE  Transmissions  (Ref  11) 


Name 

Rate  Group  Task 

Receiver 

C02  SAFE 

25 

HUD 

C03  SAFE 

25  • 

INU 

104  SAFE 

50 

HUD 

105  SAFE 

50 

FCR 

R02  SAFE 

50 

SMS 

R03  SAFE 

50 

HUD 

R04  SAFE 

25 

REO 

S02  SAFE 

50 

HUD 

SO  3 SAFE 

1.5625 

REO 

S04  SAFE 

50 

FCR 

ZOl  SAFE 

6.25 

FCR 

subsystem  to  subsystem 
rcc  to  subsystem 
subsystem  to  FCC 


C I C I G [ S 1 Data  Block  | G [Y 
T.  I Data  lUock'TG  | S j 


C j G ] S 1 Data  Block 


Vvbcre:  C - control  data  word 

S - status  data  word 
G - variable  gap  time 


Figure  9.  Data  Woid  Transmission  Formats 
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Summary 


The  OFF  is  a software  program  that  performs  primary  aircraft  mission 
functions.  These  functions  are  assigned  to  modules  of  the  OFF  called 
Computer  Frogram  Components  (CPC).  The  CPCs  are  composed  of  segments. 
Segments  are  tasks  that  are  executed  at  rates  sufficient  to  satisfy  sys- 
tem effectiveness  requirements.  Short,  service  segments  are  scheduled 
as  tasks  on  a regular,  periodic  basis  through  the  use  of  a repeating  list 
(or  queue)  system.  Lengthy,  mission  directed  segments  are  scheduled  as 
main  loop  or  background  tasks  and  execute  during  input/output  (I/O)  data 
transmissions  and  following  the  completion  of  the  service  tasks. 

All  the  tasks  that  the  OFF  executes  are  stored  in  the  FCC  memory. 

An  executive  controls  the  scheduling  and  execution  of  the  time  dependent 
tasks.  It  responds  to  a timer  interrupt.  The  duration  betxceen  interrupts 
is  20  milliseconds  and  is  called  the  minor  frame.  All  time  dependent 
tasks  have  executed  at  least  once  after  a major  frame.  A major  frame  is 
32  minor  frames  in  length. 

Main  loop  tasks  and  their  associated  service  tasks  are  scheduled 
according  to  one  of  the  fifteen  OFF  modes  of  operation.  Tliese  mode  depend- 
ent tasks  are  activated  by  the  system  control  component  and  are  assigned 
apriori  to  execute  at  a specific  rate  or  are  assigned  to  one  of  two 
repeating  queues  as  background  tasks.  The  task  interaction  is  depicted 
in  Figure  10.  The  queues  in  Figure  10  contain  the  indicated  list  of 
tasks  to  be  executed  by  the  OFF. 
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V.  DESIGN  OF  THE  SIMULATION  MODEL 


This  chapter  discusses  the  temporary  entities,  events,  subroutines, 
and  special  features  of  the  discrete  event  simulation  model  used  to  emulate 
the  F-16  fire  control  computer  operational  flight  program.  The  model 
achieves  the  goals  listed  in  Chapter  I by  simulating  the  OFF  at  the  segment 
or  task  level  for  all  OFF  modes  of  operation. 

'The  approach  was  to  develop  a simplified  version  of  the  OFF  that  would 
accurately  schedule  the  50  Hz  tasks  for  only  one  minor  frame  and  in  only 
one  mode  of  operation  (the  DOGFIGHT  mode  was  chosen).  The  model  was  then 
eiHianced  by  adding  the  other  rate  group  and  main  loop  tasks  and  extending 
the  number  of  minor  frames  that  were  simulated.  The  scheduling  of  the  mode 
dependent  tasks  was  the  final  feature  included  in  the  model.  All  segment 
attributes  are  described  by  deterministic  values.  Comments  were  included 
to  provide  a self-documented  source  program,  and  the  event  names  and 
variable  names  were  chosen  to  reflect  the  names  used  in  OFF  documentation. 
Tlie  program  source  listing  appears  in  Appendix  B. 

An  indented  sentence  structure  was  used  to  increase  code  readability. 
Continuation  lines  were  indented,  as  were  the  conditional  lines  resulting 
from  IF  stateiaents.  Groups  of  comment  lines  were  set  off  by  the  use  of 
boxes,  and  all  minor  comments  were  placed  after  column  40  on  the  source 
program  card,  as  needed. 

As  shown  in  Chapter  IV,  the  OFF  is  a network  of  interacting  queues. 
Tasks  in  these  queues  arc  executed  on  a recurring  schedule.  Because  the 
two  main  loop  tracks  arc  repeating  lists  of  tasks  (stored  in  a queue),  there 
is  never  a time  when  all  the  system  queues  are  empty.  This  permits  the 
combination  of  the  task  "arrival"  and  task  "departure"  events  discussed 


35 


in  Chapter  II.  Figure  11  shows  the  basic  concept  of  the  combination  of 
these  events. 

The  "Enter"  point  is  reached  on  an  interrupt  (timer  or  bus  controller) 
or  at  the  application  of  system  power. 

Temporary  Entities 

In  the  simulator  the  50  Hz  tasks  are  given  the  name  TS.JOB  The  TS 
is  to  designate  a 50  Hz  time  slice  cask.  Tasks  from  other  rate  groups 
(RG)  are  called  RG.JOBs.  The  main  loop  (MI.)  tasks  are  named  ML.JOBs. 

Each  task  has  the  attributes  of  normal  service  time  (**. SERVICE)  and  tasks 
name  (**.NAME).  The  service  time  is  taken  from  the  typical  execution 
time  descriptions  of  the  Product  Spec  (Ref  11)  and  is  a fixed  value  through- 
out the  simulation.  Tlie  task  name  is  an  alphanumeric  code.  Only  10  char- 
acters arc  available  for  the  name  due  to  the  simulation  language  and  the 
host  computer,  llierefore,  the  task  name  contains  the  first  10  characters 
of  the  pneumonic  code  used  in  the  Product  Spec  to  identify  the  task  with 
the  decimal  point  replaced  by  an  "X"  and  the  slash  (/)  replaced  by  an  "I." 

Since  TS  and  RG  tasks  may  be  I/O  tasks,  they  have  an  attribute  called 
TS. BLOCK  and  RG. BLOCK  respectively.  I/O  tasks  allow  the  CPU  to  execute 
main  loop  tasks  while  the  bus  controller  completes  the  I/O  tasks.  All  I/O 
tasks  "block"  or  inhibit  the  selection  of  the  next  task  from  either  the 
TS  or  the  RG  queue.  Tliis  attribute  is  set  to  "I"  for  I/O  tasks  and  to 
"0"  for  other  tasks.  This  attribute  is  set  to  "2"  for  tasks  that  are 
scheduled  only  after  a certain  background  task  has  executed. 

The  rate  group  tasks  have  an  attribute  tliat  Identifies  its  frequency 
of  execution  called  QUEUE.  Tasks  are  scheduled  according  to  the  value  of 
QUEUE,  i.e.,  all  6.25  Hz  rate  group  tasks  have  their  QUEUE  value  set  to 
"6"  and  all  of  these  tasks  are  completed  when  that  rate  group  is  scheduled. 
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Tlie  QUEUE  value  is  the  integer  value  of  the  rate  group  name.  The  QUEUE 
value  of  the  1.5625  offset  rate  group  tasks  is  a "2"  and  the  1.5625  rate 
group  tasks  are  given  a "1."  The  main  loop  tasks  have  a similar  attribute 
called  TlhlCK.  Tasks  with  a TR,.\CK  value  of  "1"  ("2")  are  assigned  to  the 
first  (second)  main  loop  task  list. 

An  entity  called  TASK  is  created  to  get  tasks  into  the  simulation. 

'Fhe  TASK  attributes  of  NAME,  SERVICE,  JB. BLOCK,  and  T. QUEUE  are  compati- 
ble with  the  executed  *''.JOB  attributes.  Main  loop  tasks  have  a T. QUEUE 
value  of  "51"  or  "52"  for  track  /‘I  and  track  #2  indentification  respec- 
tively. This  is  necessary  because  the  1.5625  and  offset  rate  groups  have 
the  values  "1"  and  "2." 

An  additional  attribute  called  DISPATCH  is  used  to  identify  one  of 
the  OFP  modes  (see  page  20)  in  which  a task  is  to  be  executed.  All  tasks 
are  read  from  data  cards  except  those  sciieduled  in  a rate  group  after  the 
completion  of  a certain  main  loop  task.  All  attribute  values  of  a task 
are  defined  on  a data  card.  Tasks  that  are  scheduled  in  all  "air-to-air" 
inodes  and  all  "FCC  .air-to-ground"  attack  modes  are  given  the  DISPATCH 
values  of  "20"  and  "21"  respectively.  Tasks  scheduled  in  all  modes  are 
given  the  value  of  "0."  A list  of  t.ask  attribute  values  appears  in  Appendix 
B. 

The  method  of  scheduling  the  proper  rate  group  is  achieved  by  reading 
the  rate  group  executing  order  from  data  cards  and  saving  the  order  in  a 
circular  queue  called  RC. ORDER.  In  addition  to  the  50  Hz  rate  group,  one 
rate  group  is  selected  on  each  minor  cycle.  The  simulator,  therefore,  has 
five  first-in-first-out  sets  to  contain  the  rate  group  scheduling  order 
and  the  four  typos  of  tasks:  TS. QUEUE  (for  50  Hz  rate  group  tasks),  RC.- 
QUEUE  (for  other  tasks),  MI.. TRACK  (for  main  loop  tasks),  INITIAL  (for 
Input  tasks),  and  RG. ORDER  (for  the  rate  group  execution  sequence). 
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Events 


Eight  events  are  used  in  the  simulator.  The  timer  interrupt  is  emu- 
lated by  the  event  CLOCK.  Tliis  event  begins  each  minor  frame  and  first 
stops  the  execution  of  a main  loop  task,  if  required.  Tlien  it  advances 
the  minor  frame  counter,  FRAME,  and  at  the  end  of  a major  frame,  it  col- 
lects some  main  loop  task  statistic.s.  If  a rate  group  task  has  not  com- 
pleted, the  simulator  indicates  the  error  by  calling  the  event  TIME. OUT. 

If  the  last  rate  group  task  has  completed,  the  rate  group  statistics  are 
collected  and  the  rate  group  global  summation  variables  are  set  to  zero. 
Tlie  number  of  major  frames  that  have  executed  are  checked  to  determine 
the  end  of  the  simulation.  The  next  clock  event  is  scheduled  in  20  milli- 
seconds and  two  mode  initialization  tasks  are  deleted.  The  arrival  of 
a 50  Hz  task  is  scheduled  after  allowing  for  the  execution  time  required 
by  the  interrupt  handler  of  the  executive.  A flowchart  for  the  CLOCK 
event  is  shown  in  Figure  12. 

The  events  TS.TASK  and  RG.TASK  are  conceptually  identical.  TlTey 
start  and  complete  the  time  slice  (50  Hz)  and  other  rate  group  tasks. 

Main  loop  tasks  are  first  interrupted,  then  a task  is  removed  from  the 
associated  queue.  Tlie  last  job  in  each  queue  has  a zero  service  time. 

This  job  is  used  to  signal  when  all  tasks  in  the  queue  have  been  executed. 
A task  is  removed  from  tlie  top  of  the  queue,  the  service  time  is  checked, 
and  the  rate  group  (m.ain  loop)  list  of  tasks  is  started  if  the  service 
time  equals  zero  for  a 50  Hz  task  (rate  group  task).  If  the  service  time 
is  not  zero,  the  same  event  is  scheduled  at  the  task  completion  time.  If 
the  **. BLOCK  attribute  is  a "1,"  a main  loop  task  is  begun.  All  tasks 
are  returned  to  their  respective  queues  except  tasks  whose  **, BLOCK  value 
equals  a "2."  For  tasks  stored  in  the  RG. QUEUE,  only  task.s  with  the  same 
value  in  the  attribute  QUEUE  arc  removed  during  a minor  frame. 


39 


The  event  RATE. GROUP  removes  the  number  to  identify  the  rate  group 
tasks  to  be  activated  during  the  current  minor  frame  from  the  queue 
RG. ORDER.  Tlie  value  is  placed  in  a global  variable,  "X."  The  global 
variable  is  used  by  the  events  RG.TASK  and  CLOCK.  Rate  group  summation 
variables  are  reset  to  zero  prior  to  starting  the  execution  of  the  rate 
group  tasks. 

The  event  MMN.LOOP  accomplishes  a similar  function  to  the  event 
RATE. GROUP,  in  that  it  determines  which  main  loop  track  should  be  executed. 
Sequentially,  the  following  steps  are  accomplished.  An  interrupted  main 
loop  task  is  restarted,  when  required.  Next,  two  jobs  are  added  to  the 
time  slice  queue  if  the  mode  is  FIX  (13)  and  the  execution  of  track  #1  has 
completed.  If  the  mode  is  FCC  air-to-ground  attack  and  track  #1  has  com- 
pleted, one  additional  task  is  added  to  the  time  slice  queue.  Tlie  next 
track  to  be  executed  is  selected  based  on  the  ratio  of  the  time  spent  in 
each  track  thus  far.  Track  §2  executes  four  times  the  rate  of  track  //I 
for  modes  10  through  15,  and  the  tracks  are  scheduled  equally  for  modes 
1 to  9. 

The  event  ML. TASK  starts  and  completes  the  execution  of  main  loop 
tasks.  It  completes  a task  by  means  of  a subroutine  called  ML. COMPLETION. 

A task  with  the  correct  track  value  is  removed  from  the  queue  ML. TRACK. 

The  interrupt  variables  are  set  to  zero.  If  the  task  service  time  is 
zero  (which  indicates  the  bottom  of  the  track  has  been  reached),  the  event 

M/MN.LOOP  is  scheduled  to  see  if  the  system  requires  a change  to  the  cur- 

rent track  being  e.xecuted.  The  variable  MI..F1.AG  is  used  to  identify  that 
a main  loop  task  in  being  serviced.  The  value  Ml.. HOLD  is  used  to  indicate 

that  a nu'iin  loop  task  has  been  interrupted.  The  variable  ML. SAVE  is  a 

global  location  to  save  the  value  of  the  task  service  time  so  that  the  task 
completion  can  bo  rescheduled  when  a main  loop  task  is  restarted  after  being 
interrupted . 
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The  event  TIME. OUT  prints  an  output  message  only  if  all  rate  group 
tasks  have  not  been  executed  when  the  timer  expires.  This  event  then 
schedules  the  event  ENT). SIM  to  stop  the  simulation  run.  This  event  is 
only  entered  after  a fault  has  been  detected  in  the  event  CLOCK. 

Subroutines 

The  routine  ML .COMPLETION  turns  the  execution  flag  of  the  main  loop 
tasks  "off,"  evaluates  (ML. HOLD)  the  time  spent  so  far  in  executing  the 
task  since  it  was  started  or  restarted,  and  adds  this  time  to  the  total 
tine  (ML. TOTAL)  spent  in  the  current  track. 

Ttie  routine  EXECUTIVE  occurs  only  once  during  the  initialization  of 
the  model  and  takes  the  tasks  that  have  been  stored  in  the  INITIAL  input 
queue  and  places  them  in  their  execution  queues  based  on  the  current  FCC 
operational  mode.  Ttie  variable  DIGILIPH  is  used  to  identify  the  task  and 
mode  compatibility.  Attributes  of  the  TASKs  stored  in  INITIAL  are  equated 
to  the  attributes  of  the  tasks  to  be  executed  (MI.. JOB,  RC.JOB,  TS.JOB). 

Tlie  job  order  of  execution  is  controlled  by  the  placement  of  the  task 
data  card  in  the  input  card  stream.  The  amount  of  executive  component 
overhead  is  supplied  in  the  form  of  an  executed  task  (OFP  Segment).  The 
EO  Weapons  mode  (11)  requires  a task  to  he  removed  from  the  executing  rate 
group  queue.  This  task  is  executed  in  all  other  modes. 

Spec  in  1 _Fea  t nr i-s 

The  task  service  times  are  all  In  milliseconds  and  the  statistics  are 
in  milliseconds.  Wlien  a task  completion  (departure)  is  scheduled,  it  is 
done  in  "x"  number  of  milliseconds  (MSEC). 

Two  one-dimensional  arrays,  RG  and  HOLD,  are  used  to  collect  the  time 
(statistics)  spent  in  executing  rate  group  tasks,  RG  is  for  the  total  time 
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and  HOLD  is  for  the  I/O  time.  Tliese  dimensioned  variables  use  the  value 


of  the  last  current  rate  group  ("X")  as  the  variable  index.  The  value  of 
"X"  is  also  used  to  add  the  dimensioned  variable  to  the  proper  summary 
variable  (for  statistical  computation). 

Tasks  that  execute  only  after  completion  of  the  3.125  rate  group  are 
assumed  to  execute  without  this  restriction.  This  makes  the  scheduling 
of  these  tasks  less  difficult.  Other  scheduling  simplifications  include 
the  deletion  of  some  minor  tasks  and  the  "worst  case"  approach  of  requiring 
all  tasks  to  be  executed  in  a given  mode  even  when  the  tasks  require  addi- 
tional conditions.  A summary  of  such  Casks  are:  6 . 15/FXPUPRC  (50  Hz), 
11.11/AGSTR.\F  and  9.1/GXINIT  (25  Hz),  11.10/AGINIT  and  6.6/FXDTCZE 
(6.25  Hz) . 

Some  tasks  are  not  scheduled  due  to  the  execution  of  a similar  task. 
Automatic  ballistics  are  substituted  for  manual  ballistics  tasks  (11.5/ 
AGM\N)  . TAK.\X  data  is  assumed  to  be  used  in  the  FIX  mode  (13)  in  place 
of  R.\DAR  data  (6 . 12/FXPUPRH) , and  RAXGE  data  is  required  in  the  FIX  mode 
instead  of  either  HOME  (7.3/CR!IOM)  or  ENDURANCE  (7.4/CREDR)  data. 
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VI.  RESULTS  AND  CONCLUSIONS 


Tills  chapter  presents  a comparison  of  the  model  statistics  with  data 
derived  from  the  hand  calculation  of  the  OFF  statistics  (without  the  model- 
ing simplifications),  and  from  a statistical  analysis  (G.D.  Report)  pro- 
vided by  General  Dynamics,  the  OFF  manufacturer,  for  the  Dogfight  and  CCIF 
modes  of  operation. 

The  effect  of  a long  (800  minor  frame)  simulation  run  was  tested  and 
the  accuracy  of  the  1/0  tasks  was  evaluated.  Tlie  conclusions  that  can  be 
made  are  stated  and  suggestions  for  model  improvement  are  discussed. 

Verification  Resul ts 

The  G.D.  Report  (Ref  13)  results  for  the  Dogfignt  and  CCIP  mode  are 
contained  in  Table  IV.  The  report  does  not  document  how  these  results 
were  obtained. 

The  hand  calculation  of  the  OFF  statistics  was  made  by  following  the 
scheduling  of  OFF  segments  for  the  first  minor  frame  after  power  up  in 
the  two  modes  of  interest.  Tlie  results  are  a summation  of  the  segment 
execution  time  by  rate  group,  or  frequency  of  execution,  as  presently 
documented  (Ref  11) . 

The  simulation  was  run  for  five  major  frames  (CYCLES)  in  the  Dogfight 
(DFG)  mode  (1)  and  the  data  comparison  appears  in  Table  TV.  The  execution 
times  in  the  table  do  not  include  tlie  1/0  tasks  assigned  to  the  respective 
rate  groups.  A significant  difference  appears  in  some  of  the  rate  groups. 
For  example.  In  the  3.125  Uz  tasks  the  G.D.  Report  indicates  the  execution 
time  to  6.0  milliseconds.  Ft  is  assumed  tliat  the  present  documentation 
(whicl)  is  a year  old)  does  not  reflect  tFie  task/qiieuc  relationships  used 
in  tlie  G.D.  Report. 
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Table  IV.  Simul.it  ion  Results  - Data  Comparison 


As  an  additional  check  on  the  model  design,  the  simulation  was  run 
for  the  CCIP  (5)  mode.  These  statistics  also  appear  in  Table  IV,  and  Che 
results  are  similar  to  the  Dogfight  mode  results. 

An  attempt  was  made  to  obtain  the  actual  time  of  segment  execution 
from  the  software  test  stand.  However,  the  present  program  source  listing 
and  the  present  AFAh  workload  did  not  permit  this  to  be  achieved.  The 
output  of  Che  model  will  be  far  more  accurate  if  the  actual  segment  service 
times  are  used  in  the  model  of  the  task  descriptions. 

The  model  was  run  for  25  major  frames  to  determine  the  effect  of  a 
longer  run.  There  is  a disadvantage  to  such  a long  simulation  run  and 
that  is  the  requirement  for  250,000  octal  words  of  primary  memory  in  the 
host  computer.  This  is  due  to  the  fact  that  completed  Casks  are  not 
destroyed,  but  are  returned  to  their  owner  set.  This  long  run  did  not 
produce  a significant  statistical  change  in  the  model  output.  The  length 
of  this  run  was  chosen  due  to  the  repeating  cycle  of  800  minor  frames 
(25  major  frames  or  16  seconds)  as  described  in  Chaj^ter  IV. 

The  output  of  the  software  test  stand  bus  monitor  unit  (BMU)  was 
used  to  evaluate  the  I/O  tasks.  A comparison  of  the  BMU  measured  (average) 
I/O  task  execution  times  and  the  model  I/O  tasks  is  shown  in  Table  V.  The 
model  was  modified  to  run  for  only  one  major  cycle  and  to  track  the  simu- 
lated time  that  had  expired  since  the  last  clock.  This  time  was  output 
after  each  I/O  task.  It  was  determined  by  this  comparison  that  the  exe- 
cuting tiroes  for  the  OFP  mode  dependent  tasks  as  measured  by  the  BMU  were 
different  from  the  documentation. 

Cone  Ins  ions 

Tlie  model  does  achieve  all  the  goals  established  in  the  beginning  of 
this  work  ns  defined  in  Chapter  I,  and  siiouid  prove  to  be  a satisfactory , 
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useful  tool  in  the  CPE  effort  of  the  OFP  analysis.  The  output  of  the 
model  can  be  used  to  accurately  predict  the  time  slice  and  main  loop 
execution  times.  However,  this  can  only  be  achieved  with  proper  input 
data.  Therefore,  more  accurate  OFP  segment  execution  times  are  needed. 

The  model  is  a true  reflection  of  the  "documented"  OFP.  The  reassignment 
of  task/queue  relationships  (step  6 in  the  approach  of  Chapter  I)  and  the 
subsequent  operation  of  the  model  to  determine  the  impact  on  the  OFP,  is 
left  to  the  AFAl.  user.  The  reader  is  cautioned  not  to  attach  more  than 
generalized  significance  to  the  model  output  until  the  segment  execution 
tines  are  updated. 

Tlie  model  will  always  bo  a good  description  of  the  OFP,  provided  the 
user  keeps  the  task  service  time  and  the  task  execution  conditions  current, 
I i a t.ask  is  added  or  deleted  from  the  OFP,  the  user  need  only  insert  or 
remc've  the  associated  data  card. 

Suggested  Improvements 

The  G.D.  Report  proposed  reassignment  of  the  I/O  data  transmission 
tasks  and  a regrouping  of  the  data  blocks  transmitted  during  a task.  This 
enhancement  is  loft  as  an  item  for  further  study.  It  could  be  implemented 
using  an  1/0  task  queue  and  an  event  to  start  and  stop  I/O  tasks.  Tlie 
present  "blocking"  attributes  would  no  longer  be  required. 

Tlie  G.D.  Report  also  contained  statistics  on  the  main  loop.  Tliese 
st.atlstics  were  on  the  number  of  solutions  per  second  and  the  milliseconds 
per  execution.  The  generation  of  these  particular  statistics  is  possible 
in  several  ways.  A per  second  statistic  could  be  generated  by  an  event 
that  is  c.alled  every  second  and  only  gathers  the  needed  statistic.  Per 
execution  statistics  could  be  gathered  in  the  event  MAIN. LOOP.  Tlie  model 
generates  statistics  on  solutions  (turns)  per  major  frame  (Cycle)  and  on 


track  execution  time  per  major  frame. 
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Another  enhancement  would  be  to  have  the  model  change  mode  automatically. 
This  could  save  a large  amount  of  time  that  is  now  spent  in  compiling  the 
source  program.  Another  desirable  feature  would  be  to  reduce  the  amount 
of  primary  memory  that  is  required  for  a longer  simulation  run. 
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APPENDIX  A 


Computer  Source  Listing  ] 

I 

i 

This  appendix  contains  a listing  of  the  computer  program  and  the  data 

as  input  to  the  simulation.  Variable  names  that  are  summarized  ' 

block  in  the  computer  program  output  listing  have  been  deleted.  ' 
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APPENDIX  B 


OFF  Segment  Definitions 

This  appendix  contains  excerpts  from  the  Product  Spec  which  describe 
the  OFF  segments  and  their  timing. 
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Table  X.  Navij^ntion  Support  Segment  Definitions 
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Table  XI.  Fixtaking  Segment  Definitions  (Sheet 
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APPENDIX  C 

List  of  Abbreviations 

Office  Symbol  of  the  Advanced  Systems  Group 

/VDC 

Analog- to-Digital  Converter 

ADP 

Automatic  Data  Processing 

AFAL 

Air  Force  Avionics  Laboratory 

AFIT 

Air  Force  Institute  of  Technology 

AFLC 

Air  Force  Logistics  Command 

BMU 

Bus  Monitor  Unit 

CADC 

Central  Air  Data  Computer 

CCIP 

Continuously  Computed  Impact  Point 

CCRP 

Continuously  Computed  Release  Point 

CPC 

Computer  Program  Component 

CPE 

Computer  Performance  Evaluation 

CPU 

Central  Processing  Unit 

DFG 

Dogfight  Mode  of  Operation 

EO 

Electro-Optical  (Weapons) 

FCC 

Fire  Control  Computer 

FCNP 

Fire  Control/Navigation  Panel 

FCR 

Fire  Control  Radar 

FCS 

Fire  Control  System 

G.D. 

General  Dynamics 

HUD 

Heads  Up  Display 

INU 

Inertial  Navigation  Unit 

I/O 

Input/Output  (Data  Movement) 

LADD 

Low  Altitude  Drogue  Delivery 

LCOS 

Lead-Computing  Optical  Sighting 

95 


ML 


Main  Loop 


MS 

Avionic  Mission  Software 

MUX 

Multiplex  (Buses) 

OFF 

Operational  Flight  Program 

OTP 

Operational  Test  Program 

REO 

Radar/EO  Display  Set 

RG 

Rate  Group 

SMS 

Stores  Management  Subsystem 

SS 

Avionic  Support  Software 

TISL 

Target  Identification  Set  Laser 

TS 

50  Hz  Rate  Group,  Time  Slice 

URT 

Universal  Remote  Terminal 

VITA 
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